Codecov Report

Merging #1341 into master will decrease coverage by -0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1341      +/-   ##
==========================================
- Coverage   99.75%   99.74%   -0.01%     
==========================================
  Files         140      140              
  Lines        2401     2394       -7     
==========================================
- Hits         2395     2388       -7     
  Misses          6        6

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a5ff572...d1c7e17. Read the comment docs.

Released in semantic-ui-react@0.65.0

question, what is the scenario where a modal does not take focus? Would it be worthwhile adding the focus stealing functionality back but put it only there?

The issues came up one at a time:

• fix(Portal): do not take focus after first render #1215 stealing focus on re-render is an issue
• fix(Portal): focus is stolen when clicking away to close #1271 stealing focus on close is an issue
• Popups and Tooltips steal focus from input fields #1324 stealing focus on open is an issue

One issue with taking focus on open (#1324) is that if the user has their cursor in an input, then they mouse over a completely unrelated popup somewhere, then the input looses focus since the popup steals focus.

I could see this also being the case if focus were required for any arbitrary element and some other unrelated Portal powered component (Dimmer, Popup, etc) were to open and take focus.

It seems there are very limited cases where changing focus makes sense, such as in some Modals and some Popups. However, only the developer knows which Popups and Modals make sense to focus and when. For instance, a Popup with a Button or Input might make sense to focus, but a tooltip does not. We have no way of knowing this information from the context of the Portal.

The conclusion is that focus management should be handled on a case by case basis using the proprietary knowledge of the implementation.

I was just curious if you had a specific use case for when a modal doesn't steal focus, cause in my mind modals always take over the screen and hence always take focus

I considered only having modals take focus, though, given the other issues I opted to leave it to the user. I think even with Modals, it only makes sense to take focus if there are controls within the Modal, such as links or buttons.

Although it makes sense to focus some Modals, I think the issues related to unnexpectedly stealing focus from other elements outweigh the benefits. There is no telling if stealing focus from elsewhere will be detrimental to the UX.

Lastly, SUI core modals do not take focus on mount either. I considered this in deciding against it by default.

Taken all together, it is sometimes useful to take/restore focus for Modals but I don't think it is always proper to do so.

If we get some more requests for focusing modals on mount, I'd like to consider adding this as a prop(s) to the Portal. This would enable users to opt-in to focus management for any Portal component. Given more requests, it may be worth the added complexity.